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INTRODUCTION - STATEMENT OF NEED 


The challenge now facing our military strategists is how to overcome the 
ever-increasing gap between the strength of our adversaries and that of our 
own existing forces. To lessen this gap, our weapon systems have become more 
complex and costly as a result of the increased demand for performance and 
in design. Both of these factors tend to exacerbate the maintenance problems. 
Fault location (diagnostics), in particular, is a maintenance task that is 
greatly affected by complexity and cost. Increased system complexity generally 
makes the fault location task more difficult, particularly when the basic skill 
level and capability of the maintenance personnel do not improve at the same 
rate as system performance. However, the increased cost of aviation systems 
and related spare parts requires that aircraft downtime be kept to an absolute 
minimum and that false removals of major components be reduced as much as is 
practical without sacrificing fault-detection capability. 

Fortunately, the technological advances that lead to improved system per- 
formance can also be used to enhance system supportability . Advanced condi- 
tion monitoring sensors, such as accelerometers and oil debris detectors, often 
permit maintenance personnel to detect and isolate a failed component soon 
after operation. Built-in test (BIT) and built-in test equipment (BITE) can 
also provide similar capabilities for electronic systems, provided the input 
parameters, test point location, and decision logic are correct (this will 
be further discussed). 

The increasing sophistication of modern aircraft, the need for greater 
aircraft availability, and the limited pool of manpower and skills available 
for maintenance have placed excessive demands on current diagnostic philoso- 
phies. In actual process, no systematic approach to fault isolation is em- 
ployed (Fig. 1). The test procedures in the technical manuals are often ig- 
nored, and "remove and replace" becomes the standard troubleshooting process. 
This may evolve into a total "shotgun approach," where all possible failed 
components are replaced. The complexity and unreliability of the field test 
equipment lead to their misuse and erroneous results. Even BIT indications 
are misinterpreted when fault codes must be interpreted and referenced in 
manuals . 
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Maintenance is a Problem Because . . . 



• . . It is based on a loosely connected flow of inadequate 
measurements and information to the human intelligence 
of the maintained 


Fig. 1. General condition at AVUM level maintenance. 


If the elements of Fig. 1 could be tied together and offer a coherent picture 
of the status of the aircraft and isolate to failed components, then an integrated 
diagnostic system would be realized. The objective of such a system is the 
transformation of available data, whether from the crew, cockpit, TM's or test 
equipment, into useful maintenance information. The system should be able 
to evaluate the usefulness of the data, reject incorrect or superfluous data, 
and aid the personnel in the determination of the proper maintenance action. 

The current approach depends heavily on the experience and training of the 
crew and maintenance personnel to both acquire and interpret the many forms 
of data available. This leads to a specialization of tasks and thus the re- 
quirement for a large number of skill specialties. An integrated diagnostic 
approach has the potential to reduce the number of skill specialties now re- 
quired and thus allow the maintenance of current capabilities even after reduction 
in force structure. 

Another important reason for integrated diagnostics and also for condi- 
tion monitoring systems was aptly detailed in a NASA study on the potential 
causes of pilot-error accidents. U.S. Army statistics have identified human 
error as the major cause in approximately 75% of all major helicopter accidents 
during the fiscal years 1978-1982. Table 1 is a summary of the results of a 
a NASA study in which 110 randomly selected U.S. Army accidents were reviewed. 
These accidents were from the following categories: Class A accidents (those 
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resulting in a fatality, permanent disability, airframe loss, or costs exceed- 
ing $500,000) and Class B accidents (hospitalization of five or more personnel, 
permanent partial disability, or costs between $100,000 and $500,000). 

TABLE I 

SUMMARY OF HELICOPTER PILOT ERROR ACCIDENTS (3) 


AGGREGATED BY AREAS OF TECHNOLOGY NEEDS (2) 






NUMBER OF 




NUMBER OF 

NUfflER OF 

INJURIES 

COST ESTIMATES 

AREAS OF TECHNOLOGY NEEDS 

MISHAPS 

FATALITIES (NONFATAL) AMOUNT 

PERCENT 

NO APPARENT TECHNOLOGY IMPLICATIONS 

5 

0 

15 

% 5,828,440 

9.3 

ALTERNATIVE TO THE TAIL ROTOR 

6 

0 

8 

1,768,799 

2.8 

ADVANCED FLIGHT SIMULATORS 

21 

5 

17 

13,216,403 

21.1 

ADVANCED FLIGHT CONTROLS AND DISPLAYS 

25 

B 

23 

15,394,824 

24.6 

OBSTRUCTION DETECTION 

20 

13 

42 

11,962,376 

19.1 

AUTOMATED MONITORING t DIAGNOSTIC SYSTEMS 29 

7 

41 

12,022,725 

19.2 

CONTINGENCY POWER 

4 

0 

9 

2,446,922 

3.9 

TOTALS FOR RECORDS REVIEWED (1) 

110 

33 

155 

$62,640,494 

100.0 


NOTES i (1) RANDOM SELECTION FROM ARMY CLASS-A AND -B ACCIDENTS 1981-1983. 

(2) NASA STUDY 

(3) HUMAN ERROR IS CAUSE FACTOR IN 75X OF ALL MAJOR ARMY ACCIDENTS 1978-1982. 
PUBLISHED IN RWI, APRIL 1986. 


As the table indicates, 29 accidents, or 26.67,, were identified in the 
NASA study as preventable with new technology to assist the pilot in monitoring 
the performance of flight-critical systems; i.e., automated monitoring and 
diagnostic systems. Researchers noted that numerous accidents involved a sequence 
of events wherein an actual or suspected in-flight failure was misinterpreted 
by the pilot/crew or incorrectly diagnosed. These findings led to recommendations 
for advanced technology to: 


1. Monitor flight-critical systems without pilot intervention. 

2. Warn of adverse trends and impending system failure. 

3. Correlate information or malfunctions. 

4. Automatically predict and monitor performance capabilities and 
power demands to assist the pilot in operating within performance limitations. 

This paper summarizes recently completed projects in which advanced diagnos 
tic concepts have been explored and/or demonstrated. The projects begin with 
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the design of integrated diagnostics for the Army's new gas turbine engines, 
and advance to the application of integrated diagnostics to other aircraft 
subsystems. Finally, a recent project is discussed which ties together subsystem 
fault monitoring and diagnostics with a more complete picture of flight domain 
knowledge . 


ENGINE DIAGNOSTICS 


APPROACH 


The successful fielding of the T-700 engine demonstrated the importance 
of incorporating maintenance and diagnostic technologies at the start of the 
design phase and not trading off this technology for other considerations (cost 
and/or weight) as the engine matured. The results of this have shown the T-700 
engine to be one of the most maintainable engines within DOD inventory. This 
philosophy of designing in diagnostics was carried over to other engine development 
programs-- the advanced technology demonstrator engine program (ATDE) and the 
modern technology demonstrator engine (MTDE). Under these efforts, the contractors 
were required to conduct diagnostic and condition monitoring studies to assess 
and identify specific diagnostic and monitoring techniques that would allow 
on-condition maintenance yet not sacrifice the safety of the pilot and crew. 

Fault isolation procedures were to be developed to identify faults to the modular 
or line replaceable unit (LRU) level. 

From these studies, a diagnostic/condition monitoring system was defined 
beginning with a determination of the right mix of sensor inputs. Parameter 
selection was first based on the data that would normally be available from 
electronic fuel controls and cockpit indications since these signals were essen- 
tially free for diagnostic usages. Typical signals are listed in Table II. 
Additional parameters could then be selected on the basis of their usefulness/ 
effectiveness within a given system. This is determined by system complexity, 
cost to monitor, and potential payback. The functions of the monitoring system 
can be generalized into: 

1. General engine health. 

2. Engine limit exceedances. 

3. Engine trending analysis. 

4. Fault isolation to the LRU/module level. 

5. Low cycle fatigue. 

6. Hot section stress. 

Table III is a compilation of the various types of parameters required 
for the above specific areas. The final selection of parameters is obviously 
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dependent on system complexity. To determine which mix of parameters and tech- 
niques should be pursued, studies were conducted on system effectiveness vs. 
cost tradeoffs. Possible engine parameters, sensors /transducers and maintenance 
indicators, and ground support equipment combinations were identified and the 
cost and effectiveness of each were determined. 


TABLE II 


CO NTROL UNIT 

T2 - COMPRESSOR INLET TEMP 
NG - GAS GENERATOR SPEED 
NP - POWER TURBINE SPEED 
0 - TORQUE 

PTIT - POWER TURBINE INLET TEHP 
P3 - COMPRESSOR DISCHARGE PRESS 
APFF - FUEL FILTER AP SWITCH 
ECUF - ECU FAULT OUTPUTS 

COCKPI T 

POIL - OIL PRESS 
TOIL - OIL TEMP : 

LOIL - OIL LEVEL 
APOF - OIL FILTER AP 
CHIP - CHIP DETECTORS 
WF - FUEL FLOW (CALCULATED) 
TFUEL - FUEL TEMP 
AICE - ANTI-ICE SWITCH 


PEA - POWER LEVEL ANGLE 
K I AS - KNOTS INDICATED AIR SPEED 
PI - AMBIENT AIR PRESSURE 
C/P - COLLECTIVE PITCH ANGLE 
NR - ROTOR SPEED 
G - AIRFRAME G LOAD 


m 

IPS - INLET PARTICLE SEPARATOR SWITCH 
CVIB - COMPRESSOR VIBRATION 
TVIB - TURBINE VIBRATION 
WOW - WT ON WHEELS SWITCH 
BLEED - CUSTOMER BLEED SWITCH 


TABLE III 

PARAMETER REQUIREMENTS 
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The various mixes of combinations are depicted in Fig. 2. Systems 1 and 
2 consisted of sensors, cockpit indication, and a maintenance indicator unit 
for the airborne portion of the system. System 3 added a data recorder/analyzer 
All systems used a portable data analyzer for ground support at the unit mainte- 
nance area with systems 2 and 3 adding a processing station at the intermediate 
level. System 3 was capable of interfacing with an airframe recorder if needed. 



Fig. 2. Condition Monitoring Concepts 

System 1 is the least complex with minimum hardware and a "no frills" approach. 
It requires active participation by maintenance personnel in most of the fault 
isolation process. All components of this system would be found at the unit 
maintenance level . 

System 2 would have an expanded data analysis capability to reduce the 
human input in the fault isolation process and thereby decrease the overall 
possibility for erroneous maintenance decisions. This system includes a data 
processing station at the intermediate maintenance level to analyze the data 
from the ground analyzer unit. This approach offers several advantages over 
the system initially described. The added airborne logic capability allows 
this system to isolate more malfunctions to cause. Field operation of this 
system would not require additional ground support equipment and the need for 
additional dynamic testing by the portable data analyzer is reduced. Data 
from the portable analyzer could be further analyzed at the processing station 
for further fault isolation and repair. 

System 3 represents a maximum capability for condition monitoring. It 
would virtually eliminate the need for manual malfunction troubleshooting. 
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An airborne recorder/analyzer would be added with this system along with an 
increased number of sensors. The recorder would be installed to record flight 
and exceedance/malfunction information. The data processing station would 
have data trending capability as well as fault isolation software. 

The maintenance philosophy for this system is a maximum analysis approach and 
requires the least human analysis and action of the three systems discussed. 
With extended in-flight condition monitoring and analysis, this system will 
predict many types of failures to reduce in-flight emergencies and mission 
aborts. Data from the cockpit display and airborne recorder would be analyzed 
either on board or at the data processing center, thus eliminating the need 
for the portable analyzer and other ground support equipment. 

SYSTEM EFFECTIVENESS 


The three systems were evaluated on their diagnostic effectiveness in terms 
of maintenance actions. The objective of the evaluation was to determine the 
overall probability of diagnosing known faults based on the individual system 
concepts and the engine parameters being monitored. In addition, costs for 
each system were established to give a system cost v.s. effectiveness comparison. 

Fig. 3 shows the results of this evaluation and indicates that an intermedi- 
ate complexity system, such as No. 2, provides the most diagnostic effectiveness 
at the least cost. System No. 1 requires a high degree of mechanic interaction 
for fault isolation without sufficient monitoring information or analysis capabil- 
ity. Therefore, the mechanic must rely on the diagnostic procedures in his tech 
manuals and on his own experience. Too often this results in erroneous decision- 
making and a lack of diagnostic effectiveness. The most complex system, No. 3, 
provides the most diagnostic effectiveness. However, there is an increase in cost 
of over twice that of System No. 2, primarily due to the requirements for an air- 
borne recorder /analyzer . In addition, a drawback of System No. 3 is the extensive 
automatic analysis and decision-making capability of the system itself. As depic- 
ted in Fig. 4, a major driver of support costs is misidentif ication of good compo- 
nents as bad. The probability of this occurrence is very high for complex compo- 
nents. Fig. 5 shows a more responsive approach than a completely analytical one. 
Here automatic decision processes will be utilized when sufficient data on the 
system condition is known. Otherwise, the system must be flexible to allow the 
maintainer to use his judgment and experience in identifying and correcting 
malfunctions . 



SYSTEM COST 

Fig. 3. Condition Monitoring Effectiveness 
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PROBABILITY OF CALLING 
A GOOD BART BAD 

Fig. A. The AutomaTic Diagnostic System Dilemmma 



Fig. 5. Optimum Approach 


ADVANCED MAINTENANCE DEMONSTRATION 


DESCRIPTION 


The capability of achieving a fully functional integrated diagnostic 
system is dependent on the incorporation of an airframe recorder/processor 
for real time data assessment and indication to the pilot and mechanic. 
However, as indicated during the engine diagnostic programs, such a system 
is cost prohibited if only applied to the powerplant subsystem. However, 
if the hardware could be used in a multifunction role, then the costs could 
be shared with other subsystems and the benefits increased to justify the 
overall procurement costs. Such a system was pursued and demonstrated under 
an Army program called "Advanced Maintenance Demonstration" (AMD). 

The AMD was initiated in 1985 as an ambitious 4-year effort to enhance 
the diagnostic and condition monitoring capabilities of current and future 
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helicopter weapon systems. This effort is comprised of building blocks from 
"off-the-shelf" technology and new technology applications. These building 
blocks are depicted in Fig. 6 and include an airborne data recorder/processor , 
ground-display computer systems, and advanced diagnostic/prognostic software 
logic using aritificial intelligence (Al) techniques. The key to achieving 
a successful diagnostics system is the integration of these technologies 
with a close regard for the human engineering disciplines; that is, how the 
mechanic in the field during combat can best utilize the data available to 
him. The system must be able to translate these vast amounts of data to 
useful, nonconfusing information. 



Fig. 6. AMD Approach 


As previously mentioned, the key to justifying the hardware costs of 
such a system is by applying the equipment in a multifunctional manner. 

The recorder/processor is no longer monitoring just the engine, but must 
record and process data from the other dynamic susbsystems plus the critical 
airframe components. Fig. 7 shows the integration of these various functions 
along with a crash survivable memory function and advancing technologies 
such as expert systems. The recorder/analyzer not only records parametric 
information but also provides diagnostic/prognostic analysis of equipment 
status and display to the cockpit and mechanic. The system also becomes 
a repository for the avionics built-in- test (BIT) data. 
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FLIGHT DATA RECORDER 
& 

FAULT ANALYZER 


Fig. 7. Program Integration 


Another essential piece of the system is an interactive maintenance aid 
that will guide the mechanic through sophisticated troubleshooting logic 
(structured around AI), as well as sort, analyze, and display data accumulated 
from the recorder such as exceedance or fault code data. The system must 
be a skill enhancement tool that can also be used for skill retention and 
on-the-job training, as well as interface with other computer equipment such 
as the automated log book (ALB) and unit level computer (ULC) systems. Figure 8 
depicts the display system being used for the demo. Although this system 
is required to download the data from the aircraft, a production system uses 
a data transfer cartridge that would fly with the aircraft. 


FUNCTIONS 

• GUIDES PERSONNEL THROUGH 
ADVANCED TROUBLESHOOTING 
LOGIC (INTERACTIVE! 

• PERFORMS TRENDING ANALYSIS 
FOR PREDICTIVE MAINTENANCE 
ACTIONS 



• ANALYZES STRUCTURAL INTEGRITY DATA FOR FLEET 
MANAGEMENT 


• DOWNLOADS DATA FOR REAR LOGISTIC APPLICATIONS 


Fig. 8. Interactive Maintenance Aid 
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However, the most important component of any diagnostic system is the 
software-- the decision logic which ultimately guides the mechanic to the 
correct maintenance action. Recorders, processors and color graphic displays 
can be very advanced to the point of complete automation or even voice activation 
However, they become burdensome tools if the logic cannot distinguish a good 
versus a bad component. The software for the AMD diagnostic logic uses available 
techniques based on typical analytical procedures as well as AI techniques 
using expert systems procedures. 

The AMD system was placed on AH-64 and UH-60 aircraft. The system involved 
the recording of selected parameters from the dynamic and structural components. 
To restrict excessive costs, every effort was made to utilize existing sensors. 

In order for this to be successful, the functions of the system had to first 
be defined. These included: 

(1) Exceedance data from engine, rotor, drivetrain, etc. This data 
is to be analyzed and stared for pilot advisory as well as mechanic retrieval. 

(2) Engine performance data to predict powerplant capabilities and 
to automatically perform "hit" checks. 

(3) Engine usage and trend data. 

(4) Structural usage data. 

(5) Flight regime recognition data. 

(6) Data for gross weight estimation. 

(7) Load severity data. 

(8) Life assessment data to calculate damage accrual rates. 

(9) Component operating data for troubleshooting and inspection 

queuing . 

(10) Accident and crash investigation data. 

Tables IV and V list the various parameters for the UH-60 and AH-64 re- 
spectively. The AH-64 multiplex (MUX) bus traffic provided approximately. 

600 digital data points for diagnostic/condition monitoring purposes. This 
data was recorded at appropriate rates to preserve resolution and fidelity. 

Since recorders can only provide a finite storage capability, various compres- 
sion techniques must be utilized. Data from vibration and direct strain 
measurements must be conditioned prior to recording due to the higher sample 
rates for such signals. 
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TABLE IV 


UH-60A PARAMETERS {40 TOTAL) 


CONTINUOUS (24 TOTAL) 

ALTITUDE {BAROMETRIC) 

ALTITUDE IRADAR) 

ALTITUDE RATE 
AIRSPEED 

01 ENGINE TORQUE 

02 ENGINE TORQUE 

01 ENGINE RPM |NG| 

02 ENGINE RPM |NG] 

01 ENGINE RPM |NP) 

02 ENGINE RPM|NP| 

01 ENGINE TEMPERATURE |T5| 

02 ENGINE TEMPERATURE |T5j 
MAIN ROTOR SPEEO (NR) 

COLLECTIVE STICK POSITION 
LONG STICK POSITION 
LATERAL STICK POSITION 
LOAD FACTOR {NZj 

PITCH ATTITUDE 
ROLL ATTITUDE 
HEAOING 

OUTSIDE AIR TEMPERATURE |OAT| 
STATIONARY SWASHPIATE LOAD 
STABILATOR POSITION 


DISCRETE (16 TOTAL) 

01 ENGINE OIL PRESSURE 

02 ENGINE OIL PRESSURE 

01 ENGINE CHIP DETECTOR 

02 ENGINE CHIP DETECTOR 
ENGINE FIRE 

APU OIL PRESSURE 
SAS WARNING 

01 ENGINE HYDRAULIC PUMP PRESSURE 

02 ENGINE HYDRAULIC PUMP PRESSURE 
INPUT LH CHIP 

INPUT RH CHIP 
ACCESSORY LH CHIP 
ACCESSORY LH CHIP 
INTERMEDIATE TRANSMISSION CHIP 
TAIL TRANSMISSION CHIP 
MAIN MIDDLE SUMP CHIP 


SAS/EPS COMPUTER FAULT 


TABLE V 

AH-64A PARAMETERS (625+ Total) 


MIL STD 1553A DATA BUS PARAMETERS 
1600 + Total) 

FAULT DETECTION/LOCATION SYSTEM 
TARGET ACQUISITION DESIGNATION 
SIGHT /PILOT'S NIGHT VISION SENSOR 
AIR DATA SENSOR 
30MM GUN 

HELLFIRE MISSILE SYSTEM 

2.75 IN ROCKET SYSTEM 

HEADING ATTITUDE REFERENCE SYSTEM 

INTEGRATED HELMET DISPLAY SYSTEM 

OPTICAL RELAY TUBE 

FLIGHT SYSTEM 


CRASH DATA PARAMETERS NOT ON BUS 
[25 Total) 

01 ENGINE FIRE 

02 ENGINE FIRE 
AUXILIARY POWER UNIT FIRE 

01 ENGINE RPM (NG) 

02 ENGINE RPM (NG) 

01 ENGINE RPM (NP) 

02 ENGINE RPM (NP) 

01 ENGINE TEMPERATURE (TGT) 

02 ENGINE TEMPERATURE (TGT) 
STATIONARY TAIL ROTOR CONTROL LOAD 
STATIONARY SWASHPIATE LOAD 

MAIN ROTOR SPEED 
LATERAL STICK POSITION PILOT 
LONGITUDINAL STICK POSITION PILOT 
COLLECTIVE POSITION PILOT 
PEDAL POSITION PILOT 
STABILATOR POSITION 
PRIMARY HYDRAULIC PRESSURE 
UTILITY HYDRAULIC PRESSURE 

01 ENGINE CHIPS 

02 ENGINE CHIPS 

MAIN TRANSMISSION 01 CHIPS 
MAIN TRANSMISSION 02 CHIPS 

01 NOSE GEARBOX CHIPS 

02 NOSE GEARBOX CHIPS 
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A key characteristic of the on-board system is the time-tagging of fault 
data. This process allows analysis of a wide range of data associated with 
the problem to identify and isolate intermittent faults which are a signifi- 
cant contribution to false removals , repetitive maintenance, and extended 
manual troubleshooting efforts. 

A typical scenario begins with a preflight inspection to ensure that 
the system is operating and storage space is available. (The recorder has 
an indication to alert the crew when 80% capacity is reached.) The pilot 
brings the aircraft into steady-state condition and then presses a button 
for the system to perform an automatic engine assessment check. The results 
of this check are reported to the pilot in the form of a go/no go indicator. 

The actual parametric data is stored for later retrieval and trending. During 
the mission, the pilot has the option to activate the recorder when he feels 
something is abnormal. Otherwise, the recorder records only faults, exceedances, 
and/or parameters that exceed predetermined "windowed" values. Upon return 
to base, the mechanic checks the recorder for any indication of a fault or 
exceedance. If the indicator is lit, the mechanic can then use the portable 
display to retrieve this data only and display it for quick assessment of 
the aircraft. If further troublshooting is required, the complete data package 
can be retrieved from the cartridge and decompressed off-aircraft for inspection 
and analysis. Fault tree logic resident within the potable maintenance aid 
interacts with the recorded data and the mechanic to help resolve and identify 
the location of the problem. 

If the aircraft lands and no fault or exceedance is indicated, then the 
mechanic can either download the data from the cartridge or bolt the covers 
back in (provided the recorder has not reached 80A storage capacity). 

The exceedance/fault data which the mechanic can inspect alongside the air- 
craft can be displayed ip various formats. The following figures show current 
examples of these formats. Fig. 9 lists a series of engine temperature record- 
ings with the allowed time at temperature. When an exceedance has occurred re- 
quiring a maintenance action, the appropriate tech manual (TM) reference is cited. 
In future, more powerful systems, the complete text of the TM can be shown and 
thus entirely eliminate paper on the battlefield. 

I ALLOWABLE SEC) RECORDED TRBLESHDOT/ 

EN6INE STATE BEFORE BEFORE SECONDS NAINTENANCE 
TSHOOT NAINT • 1EN6 KEN6 tlENo KENS 


NG<GI T4, 5)851 

1 

12 

0 

0 

NS >61 T4,5>858 

12 

60 

0 

0 

NS >6 I T4. 5)884 

0 

60 

0 

0 

NS)SI T4. 5)902 

0 

55 

0 

0 

NG/GI T4. 5)906 

0 

50 

0 

• 

NS >61 T4. 5)910 

0 

46 

0 

0 

NG>SI 14.5)914 

6 

42 

0 

0 

N6 >61 T4. 5)918 

0 

38 

0 

0 

NS >61 14.5)922 

0 

34 

0 

0 

NS)BI T4. 5)926 

0 

30 

0 

0 

NS)GI 14.5)930 

0 

26 

0 

0 

NS)SI T4. 5)934 

0 

22 

0 

0 

NS/SI T4.5)93B 

0 

18 

0 

0 

N8)6I T4. 5)942 

0 

15 

0 

0 

N6)6I T4. 5)946 

0 

12 

0 

0 

NS)GI T4. 5)950 

0 

0 

0 

0 


REF: TH55-284B-248-23 PP Ml? PARA 1-223 
Fig. 9. Engine Overtemp Report 
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Fig. 10 shows a hard landing report based on negative feet per second. 
Another way of measuring this would be to place a load sensor on the landing 
gear. By identifying the extent of a hard landing, much confusion as to 
what inspection and repair tasks are required can be avoided. In addition, 
a history of hard landings can be trended for an aircraft, better enabling 
a mechanic to schedule maintenance and to predict potential problems before 
they occur. 

LANDING VERTICAL SPEEDS 

0-2 2-4 4-6 6-8 8-10 10 

# LANDINGS FPS FPS FPS FPS FPS FPS 

AT SPEED= 3 2 0 0* 0* 0* 


TIME OF HARDEST 06:23:17.473 

NO VERTICAL SPEEDS > 6 FPS RECORDED 

NO SPECIAL INSPECTIONS REQUIRED 

REF: IM55-1520-237-23-4 TASK 9 PP 9-16 


Fig. 10. Hard Landing Report 


Figures 11 and 12 show reports for engine and rotor overspeed, respectively. 
Fig. 13 is a report for discrete indicators. These discrete indicators are 
the various caution/advisory data that is displayed in the cockpit. Time- tagging 
these indicators can greatly help the mechanic in trying to resolve pesky, 
intermittent failures that often cannot be duplicated on the ground. 


(ALLOWABLE -SEC'S) 

ENG SPEED BEFORE BEFORE 

TSH00T MAIN! 

NP>110% - 12 

NP> 113% 0 12 

NP> 130% ° 


RECORDED TRBlESHOOTf 

SECONDS MAINTENANCE 


01ENG 

02ENG 

01 ENG 02ENG 

14.7 

2.3 

M 

0.0 

1.8 

T 

0.0 

00 



ENGINE OVERSPEED ACTION REQUIRED: (M) (T) 


REF: TM55— 2840— 248— 23 PP 1-419 PARA I-222A 


Fig. 11. Engine Overspeed Report 


1224 



SIKORSKY UH60A / LSI IFIOS NVH SUHHARY 
82-23719 14:38:39 1/15/87 

NR OVERSPEED REPORT 

ROTOR SPEED RANGE 

112- 187- 112- 117- 122- 127- 132- 137- > 

1871 1121 1171 1221 127X 1321 1371 1421 142X 
REC’D * * * 

HIN= 8.8 


NO ROTOR SPEEDS > 1271 RECORDED 
NO SPECIAL INSPECTIONS REQUIRED 
REF: TH55- 1 528-237- 23-4 TASK9 PP 9-14.1 


Fig. 12. NR Overspeed Report 


SIKORSKY UH68A / LSI IFIOS NVH SUHHARY 
82-23789 14:38:39 1/15/87 

DISCRETE REPORT 


N0.1 ENGINE OIL PRESSURE 
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Fig. 13. Discrete Report 
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BENEFITS 


The objectives of such an integrated diagnostic approach are many: reduce 

repetitive and incorrect maintenance, reduce the requirement for special 
inspections and special purpose test and support equipment, provide adequate 
information to allow mechanic cross training and MOS consolidation, provide 
capabilities for card level fault isolation (two-level maintenance concept), 
provide for critical parts tracking, increase overall aircraft safety, etc. 

Most of these objectives are being realized through data processing and analysis 
off-aircraft. However, a more efficient manner of accomplishing increased 
aircraft safety would be through an on-board system which integrates all 
available flight information with the condition monitoring system. Just 
such a system has been defined in a recent NASA effort titled "An Artificial 
Intelligent Approach to On-Board Fault Monitoring and Diagnosis for Aircraft 
Application . " 


AI MONITORING SYSTEM 


INTRODUCTION 


The above research effort was initiated to identify guidelines for automation 
of on-board fault monitoring and diagnosis and associated crew interfaces. 

The effort began by determining the flight crew's information requirements 
and the various reasoning strategies they use. Based on this information, 
a conceptual architecture was developed that encompasses all aspects of the 
aircraft's operation, including navigation, guidance and control, and subsystem 
status. This architecture has two facets: the organization of flight domain 

knowledge and the problem solving process that uses this knowledge for condition 
monitoring and diagnosis. 

ORGANIZATION OF FLIGHT DOMAIN KNOWLEDGE 


Fig. 14 depicts the various categories and interconnectives for flight 
domain knowledge. Each level in the goal hierachy is subservient to the 
one above it in the sense that it supplies the means of achieving the goals 
passed down to it from above. Each level provides a goal which the level 
beneath it must attempt to achieve. It is important to notice that there 
may be many different ways of achieving a particular goal; all are correct. 

The knowledge in each level must contain information not only on how to describe 
a way of achieving a particular goal but also (and perhaps more importantly) 
on how to determine if a particular means can or cannot satisfy a goal. 
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EXTERNAL FACTORS 


GOAL HIERARCHY 



Fig. 14. Organization of Flight Domain Knowledge 


There are categories of information which are not levels in the goal 
hierarchy but are external inputs to different levels. The atmospheric in- 
formation (such as, wind, temperature, and pressure) is a set of inputs to 
various levels which must be taken into account when determining how to 
achieve a goal. Another such category is actual pilot actions for setting 
control inputs, switch settings, and so on. Still another category is infor- 
mation and instructions received from Air Traffic Control (ATC) in the form 
of ascent, descent, and heading commands. 

This organization of flight domain information corresponds to a taxonomy 
of the faults in flight which might lead to accidents. The term ,, fault 1 ' 
refers to any problem which may result in some goal not being achieved if 
not corrected or compensated, as well as failure in a physical system. This 
is an important distinction in the flight domain because problems such as 
wind shear or the pilot giving incorrect inputs can endanger the aircraft 
just as much as a physical system failure. 

FAULT MONITORING AND DIAGNOSTICS FRAMEWORK 


A framework for the fault monitoring and diagnosis process was developed 
as a result of interviewing aircraft pilots and examining pilot handbooks. 
Although this framework is described in the context of a specific domain 
(i.e., engines), it is believed to be a general framework for fault monitoring 
and diagnosis. It was not intended to model the cognitive process that humans 
use for fault diagnosis but to facilitate development of representative and 
remaining methods for fault diagnosis and its automation. 

The components of the framework are shown in Figure 15 as well as examples 
of the input and output for each component. As shown, the fault monitor, 
the fault diagnosis process, and the interface mechanism to the flight crew 
are all separate components. The purpose of the fault monitor is to detect 
when a fault occurs by examining sensor readings and generating symptoms 
which represent the abnormal values. These symptoms are the input to the 
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fault diagnosis process, whose purpose is to suggest fault hypotheses which 
isolate the cause of the symptoms. The diagnosis process is divided into 
three stages, each with a different reasoning strategy and representation. 
Stages are organized in order of increasing computational and representational 
complexity, much like humans use diagnosis strategies. Each stage is entered 
when prior stages are unsuccessful at diagnosing the current failure. The 
interface mechanism displays the diagnoses in an appropriate format to the 
flight crew. The interface mechanism must be sensitive to flight phase and 
crew workload. 


INPUTS 
TO ACFT 


QUANTITATIVE QUALITATIVE HYPOTHESIZED 



PILOT 


Fig. 15. Fault Monitoring and Diagnosis Process 


The fault diagnosis process has several stages, as shown in Fig. 16. 
Each stage uses different representations and reasoning strategies. In the 
first stage, the symptoms are compared to fault -symptom association known 
a priori. These associations are a compilation of knowledge about known 
faults and their behavior. This stage corresponds to traditional expert 
systems approaches and is attempted first because it quickly identifies the 
most commonly occurring faults. 

IDENTIFICATION OF FAULT 



Fig. 16. Fault Diagnosis Stages 


The second stage of the diagnosis process occurs when the current symp- 
toms fail to correspond to a known fault. The purpose of the reasoning at 
this stage of the diagnosis process is to localize the failure and to gener- 
ate as much information about the fault as possible. To generate the desired 
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information about the fault, the diagnostic reasoning in the second stage 
focuses on how the physical system works rather than on how the system fails, 
as was done in the first diagnosis stage. Models of functional and physical 
structure are used to provide the knowledge on how the system works. 

Since all parameters are not observable and other factors such as system 
feedback are present, localization of the failure may not be possible without 
further information. In this situation, the third diagnosis stage is entered. 
Depending on the domain, performing tests to obtain further information may 
be done passively or actively. The third stage is responsible for proposing 
tests to obtain additional information, whether the tests are active or pas- 
sive. In either case, the fault diagnosis system may be able to use the 
results to identify faults. 

Implementation of this architecture is under development. A computer 
program called INFAMOS (Intelligent Fault Monitoring System) is being developed. 
The fault diagnosis system is being implemented in a computer program called 
DRAPHYS (Diagnostic Reasoning About Physical Systems). The first application 
of these models will be an aircraft turbofan engine. 

FUTURE NEEDS 


Most of the technology required to implement effective integrated diagnos- 
tics and other maintenance aids is available today. To be truly effective, 
several things must happen. First, this technology must be applied both 
to mission equipment and to aircraft subsystems. This requires a systems 
level design of the performance monitoring equipment, including subcontrac- 
tor supplied BIT, in order to ensure complete coverage. Detail appropriate 
to the maintenance concept for the system must be available from the monitor- 
ing subsystem. An aircraft designed for three-level maintenance only requires 
fault isolation to the LRU level whereas, a two-level maintenance concept re- 
quires fault isolation to the module or card level. This places an increased 
level of complexity for the testability design of the component. 

Sensor development is required to improve not only accuracy but also 
repeatibility and reliability. An integrated diagnostic system may have 
the most efficient architecture possible with the most advanced and tested 
software logic incorporated; however, the answers will always be wrong if 
the inputs are not correct. In addition, development is needed in the area 
of load measurements where current strain gauges are high bandwidth signals 
which require preprocessing or data extraction prior to transmission to a 
data bus or flight recorder. 

A final and really most important area is the development of the dis- 
crimination logic between good and bad components. In the mechanical system 
with its myriad of failure mode combinations and resulting symptoms, complex 
systems currently prohibit simple and direct techniques to determine when 
a component has reached its expected life. Identical components operated 
under similar conditions may still exhibit different symptoms for identical 
failure modes. Vibration analysis has been hindered by this phenomenon pri- 
marily due to the intense processing requirements and overall sophistication 
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of the techniques. However, as embedded processors become more powerful and 
memory less expensive, new analysis techniques can be implemented in attrac- 
tive designs. What is still needed are the test methodologies to M nail down" 
the good versus bad signatures and how to use this data to alert the mechanic 
of impending failures prior to catastrophy but yet allow maximum usage of 
the component. 

CONCLUSION 


Application of these integrated design concepts to the next generation air- 
craft will provide substantial improvements in combat sustainability and 
in reducing logistic burdens and operating and support costs. Measured 
against today 1 s systems, the next generation can be more capable, with the 
added complexity that capability demands, and still require less reserves 
both in personnel and material. All the technologies required to implement 
these designs are emerging and will be mature within the next few years. 

The challenge in achieving these gains is management of larger development 
or product improvement integration teams, and imposing system level design 
requirements up front to ensure that design goals are met. 
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